Skip to content

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Oct 19, 2025

This data structure makes more sense alongside all the other lists in this file like COMPILE_TIME_SETTINGS and DEPRECATED_SETTINGS.

One of the main reasons for having LEGACY_SETTINGS in settings.js was that it was visible for those directly browsing the .js file. However, we now have an auto-generated .rst file that is the more common way for folks to read about settings.

See https://emscripten.org/docs/tools_reference/settings_reference.html

I updated this auto-generated document to contain this info.

This data structure makes more sense alongside all the other lists in
this file like `COMPILE_TIME_SETTINGS` and `DEPRECATED_SETTINGS`.

One of the main reasons for having `LEGACY_SETTINGS` in settings.js was
that it was visible for those directly browsing the `.js` file.
However, we now have an auto-generated `.rst` file that is the more
common way for folks to read about settings.

See https://emscripten.org/docs/tools_reference/settings_reference.html

I updated this auto-generated document to contain this info.
@juj
Copy link
Collaborator

juj commented Oct 20, 2025

When I search for code related to settings, I first go to src/settings.js, then to src/settings_internal.js.

It seems that after this, I also need to go to a third file tools/settings.py. It was convenient to have those settings in src/settings.js, it was then more coherently in the same place for fewer files to search.

I wonder if the doc generator could read the data structure from the src/settings.js file?

If that's complicated, then I don't feel strongly. LGTM either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants